The goal of the Retro Native Forth project has been expressed many times in various articles, emails, and forum postings. In case you are new to the project, our goal is to create a simpler operating system. What does this mean, and how can we make a simple operating system without sacrificing usability?

Retro has had many false starts. The first four releases by Tom Novelli paved the road for the creation of the current work. Each of the earlier releases gained simplicity in the codebase, but failed to provide a working environment. Sure you could write small programs in Forth, but beyond that it was useless. I started work on what became Retro 5 in an effort to turn Retro 4 into a complete operating system. At its height it was quite powerful. There was a debugger, editor, Forth interpreter/compiler, and support for things like persistance. As it continued to be developed, I grew to realize that it was becoming overly complex. To avoid allowing more complexity into the system, I aborted it and began work on what has become Retro 6.

I had expected Retro 6 to take several months to get into a workable state. I needed to move beyond the limitations that had existed since Retro 4. It's still not fully ready, but is far more powerful than the prior releases. I have gone back over the source many times, writing, rewriting, and factoring code. Redundancy is far less. Much more code is written in Forth. It is a nice system for my use.

Many complex pieces of code will come to Retro. How can we ensure a simple operating system if we are using complex code? There are two key methods that we will use. First we will make a minimal codebase. A common set of words and functionality that can be implemented with either text or VGA output. This will provide a simple, common baseline for Retro. Beyond this is an entire set of options. Retro will be able to support things like preemptive multitasking, multiple sessions, multiple processes per session, an intelligent sidebar, executable keymaps, runtime linker for RDF or ELF modules, runtime assembler, possibly a runtime C compiler. Under Linux (or other supported "host" operating systems) Retro will be able to use various libraries written in C or other languages.

To ensure simplicity, we will be writing each of these pieces from scratch. Simplified versions of SVGALIB and Allegro will be written. These will be forks, carefully tuned, trimmed, and revised for use with Retro under Linux. There will be several options for multitasking. Each will be mostly compatible, using a common set of words. The implementation will be independant of the interface to them. The executable keymaps will simply have a frontend that is called KEY. Just  like now, programs that use KEY will get a byte from the keyboard. How it works is dependent on the backend, which the user never needs to worry about. Other areas will be handled in a similar manner.

Of course, there will always be a truely minimal core that can be download separate. Other components will be availible as separate downloads. There's no need to worry about picking up everything, if you just need a few extensions.  Then again, for those who do need or want it all, a complete, preconfigured download will also be provided. Retro's inherent simplicity is the key to its flexibility. If it was not simple, we could not provide features like these in a useful manner. Perhaps more programmers will see the advantages of simplicity when we have a 5k kernel, 5k Forth, and similarly sized GUI, C compiler, assemblers, and applications.